Access control

In order to secure a computer and its resources, you must take into consideration what rights users will have. You can secure a computer or multiple computers by granting users or groups specific user rights. You can secure an object, such as a file or folder, through assigning permissions to allow users or groups to perform specific actions on that object.

  • For tips about access control, see Best practices.
  • For help with specific tasks, see How to.
  • For general background information, see Concepts.


Best practices

  • Best practices for permissions and user rights
  • Best practices for assigning permissions on Active Directory objects


Best practices for permissions and user rights

Assign permissions to groups rather than to users

  • Because it is inefficient to maintain user accounts directly, assigning permissions on a user basis should be the exception.

Deny permissions should be used for certain special cases

  • Use Deny permissions to exclude a subset of a group which has Allowed permissions.
  • Use Deny to exclude one special permission when you have already granted full control to a user or group.

Use security templates

  • Rather than set individual permissions, use security templates whenever possible. For information on security templates, see Security Templates.

If possible, avoid changing the default permission entries on file system objects, particularly on system folders and root folders

  • Changing default permissions can cause unexpected access problems or reduce security.

Never deny the Everyone group access to an object

  • If you deny everyone permission to an object, that includes administrators. A better solution would be to remove the Everyone group, as long as you give other users, groups, or computers permissions to that object.

Assign permissions to an object as high on the tree as possible and then apply inheritance to propagate the security settings through the tree

  • You can quickly and effectively apply access control settings to all children or a subtree of a parent object. By doing this, you gain the greatest breadth of effect with the least effort. The permission settings you establish should be adequate for the majority of users, groups, and computers.

Privileges can sometimes override permissions

  • Privileges and permissions may disagree, and you should know what happens if they do. For more information, see Privileges.

For permissions on Active Directory objects, make sure you understand the best practices specific to Active Directory objects

  • Active Directory has its own set of best practices regarding permissions. For more information, see Best practices for assigning permissions on Active Directory objects

    • For more information, see To assign user rights for your local computer and To set, view, change, or remove file and folder permissions.

    Notes

    • Inherited Deny permissions do not prevent access to an object if the object has an explicit Allow permission entry.
    • Explicit permissions take precedence over inherited permissions, even inherited Deny permissions.


Best practices for assigning permissions on Active Directory objects

For information on security and access control in Active Directory, see Securing Active Directory and Access control in Active Directory.

If possible, avoid changing the default permissions on Active Directory objects

  • Changing default permissions could cause unexpected access problems or reduce security.

Avoid granting Full Control permissions over an object or organizational unit

  • Granting someone Full Control allows them to take ownership of an object and modify the permissions on it. If someone has Full Control on a container, then they can Take Ownership of, and have Full Control over, all objects in that container. As far as possible, instead of allowing Full Control, give only the permissions needed by the user.

Minimize the number of access control entries that apply to child objects

  • When using the Apply Onto option to control inheritance, be aware that not only will the specified objects inherit that access control entry (ACE) but all child objects will also receive a copy of that ACE. If there are enough objects that will get copies of this ACE, then that increased amount of data can cause performance problems on your network.

When possible, assign the same set of permissions to multiple objects

  • Access control lists (ACLs) in the Windows Server 2003 family feature single-instancing: If multiple objects have identical access control lists (ACLs), then Active Directory will only store one instance of the ACL. For more information on how inheritance works for Active Directory objects, see Changing inherited permissions.

When possible, assign access rights on a broad level rather than assigning individual user rights

  • Minimizing the number of access control entries will improve performance.
  • Allow "Read All Properties" or "Write All Properties" rather than individual properties.
  • Allow Read or Write access to property sets rather than individual properties.

    A property set is a collection of attributes. For example, the Personal Information property set includes the attribute's address, personal title, and so on. By setting access on the property set, you have automatically set access on all the attributes contained in that property set.

  • Allow "Create All Child Objects" or "Delete All Child Objects," rather than specifying individual child objects.
  • Allow "All Extended Rights" rather than allowing the individual extended rights.
  • Allow "All Validated Writes" rather than allowing the individual validated rights.

    • Note

    • There are times when assigning individual permissions is appropriate. For example, if a Help Desk operator needs Write access to two properties of a User object, then it makes sense to use one access control entry (ACE) for each of them, rather than trying use only one ACE by granting write access to the entire user object.

Whenever possible, assign permissions to groups rather than users

  • Use groups to delegate authority over the directory. If one set of users needs Read permissions, and another set of users needs Change permissions, then create one group for each set of users and assign the permission to the group. If multiple global groups need the same access, create a local group containing the global groups and assign permissions to the local group.

    • For more information, see Active Directory object permissions.

    Caution

    • The operation of your domain may become impaired if the total size of all the Active Directory permissions approaches the disk storage or processing speed capacity of your domain controller. Minimize the number of individual permissions that are propagated to child objects.

    Notes

    • Inherited Deny permissions do not prevent access to an object if the object has an explicit Allow permission entry.
    • Explicit permissions take precedence over inherited permissions, even inherited Deny permissions.


How to...

  • Set, view, change, or remove permissions on an object
  • Secure a file or folder
  • Apply or modify permission entries for objects using Group Policy
  • Take ownership of a file or folder
  • View effective permissions on files or folders


Set, view, change, or remove permissions on an object

Microsoft Windows Graphic

To set, view, change, or remove permissions on an object

  • Set, view, change, or remove permissions on files and folders
  • Set, view, change, or remove special permissions
  • Set permissions on a shared resource
  • Assign permissions to a registry key
  • Set or remove permissions for a printer
  • Change the permissions a user or group has to a connection
  • Authorize WMI users and set permissions


Set, view, change, or remove permissions on files and folders

Microsoft Windows graphic

To set, view, change, or remove permissions on files and folders

  1. Open Windows Explorer.
  2. Right-click the file or folder for which you want to set permissions, click Properties, and then click the Security tab.
  3. Do one of the following:
    • To set permissions for a group or user that does not appear in the Group or user names box, click Add. Type the name of the group or user you want to set permissions for and then click OK.
    • To change or remove permissions from an existing group or user, click the name of the group or user.
  4. Do one of the following:
    • To allow or deny a permission, in the Permissions for User or Group box, select the Allow or Deny check box.
    • To remove the group or user from the Group or user names box, click Remove.

Notes

  • XOX
  • In the Windows Server 2003 family, the Everyone group no longer includes Anonymous Logon.
  • You can only set file and folder permissions on drives formatted to use NTFS.
  • To change permissions, you must be the owner or have been granted permission to do so by the owner.
  • Groups or users that are granted Full Control for a folder can delete files and subfolders within that folder, regardless of the permissions that protect the files and subfolders.
  • If the check boxes under Permissions for User or Group are shaded or if the Remove button is unavailable, then the file or folder has inherited permissions from the parent folder. For more information on how inheritance affects files and folders, see Related Topics.
  • When adding a new user or group, by default, this user or group will have Read & Execute, List Folder Contents, and Read permissions.

Related Topics


Set, view, change, or remove special permissions

Microsoft Windows graphic

To set, view, change, or remove special permissions

  1. Right-click the object you want to set advanced or special permissions on, click Properties, and then click the Security tab.
  2. Click Advanced, and then do one of the following:
    3. To | Do this
Set special permissions for an additional group or user | Click Add. In Enter than object name to select (examples), type the name of the user or group, and then click OK.
View or change special permissions for an existing group or user | Click the name of the group or user, and then click Edit.
Remove an existing group or user and its special permissions | Click the name of the group or user and then click Remove. If the Remove button is unavailable, clear the Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here check box, and then click Remove.
  3. In the Permissions box, select or clear the appropriate Allow or Deny check boxes.
  4. In Apply onto, click the folders or subfolders you would like these permissions to be applied to.
  5. To configure security so that the subfolders and files will not inherit these permissions, clear the Apply these permissions to objects and/or containers within this container only check box.
  6. Click OK, and then, in Advanced Security Settings for ObjectName, click OK.

Caution

  • If you select the Replace permission entries on all child objects with entries shown here that apply to child objects check box, then all subfolders and files will have all of their permission entries reset to those inheritable from the parent object. Once you click Apply or OK, you cannot undo this operation by clearing the check box.

Notes

  • XOX
  • The Everyone group no longer includes the Anonymous Logon permission.
  • If you select the Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here check box, then this file or folder will inherit permission entries from the parent object.
  • You can only set permissions only on drives formatted to use NTFS.
  • If the check boxes under Permissions are shaded, the permissions are inherited from the parent folder.
  • To change permissions, you must be the owner or have been granted permission to do so by the owner.
  • Groups or users that have been granted Full Control for a folder can delete files and subfolders within that folder, regardless of the permissions that protect the files and subfolders.

Related Topics


Secure a file or folder

Microsoft Windows graphic

To secure a file or folder

  1. Open Windows Explorer, and then locate the file or folder you want to secure.
  2. Right-click the file or folder, click Properties, and then click the Security tab.
  3. In Group or user names, click the group or user that you want to change permissions for.
  4. For users and groups that do not need the permission, clear the appropriate Allow check box, particularly for Full Control.
  5. For the users and groups that need to use the file or folder, select the appropriate Allow check box for the permissions that are needed.
  6. Repeat steps 3-4, as needed.

Notes

  • XOX
  • The process of securing a file, folder, or other computer resource is sometimes called lockdown.
  • Files and folders usually are sufficiently locked down by default.
  • Incorrect permissions can cause security vulnerabilities and access problems, so locking down should be done cautiously and only when security considerations require it.
  • Share permissions, not just NTFS permissions, can prevent access to a file or folder. Share permissions are not included in effective permissions calculations.
  • An administrator can take ownership of any file on the computer.
  • In the Windows Server 2003 family, the Everyone group no longer includes the Anonymous Logon group.

Related Topics


Apply or modify permission entries for objects using Group Policy

Microsoft Windows Graphic

To apply or modify permission entries for objects using Group Policy

  1. Open Microsoft Management Console.
  2. On the File menu, click Add/Remove Snap-in, and then click Add.
  3. Click Group Policy Object Editor, and then click Add.
  4. In the Group Policy Wizard, on the Select Group Policy Object page, click Browse.
  5. In Browse for a Group Policy object, do one of the following:
    • To use an existing non-local Group Policy object (GPO), select a Group Policy object in the appropriate domain, site, or organizational unit, click OK, and then click Finish.
    • To create a new non-local Group Policy object, in the Domain, OUs and linked Group Policy Objects box, right-click in an empty area, click New, type the name of the new Group Policy object, click OK, and then click Finish.

    Note

    • If the Browse for a Group Policy object dialog box has only one tab, and it has the label Computers, then you only have access to local Group Policy objects and you cannot complete this procedure. This probably means the computer is not joined to an Active Directory domain.
  6. Click Close, and then click OK.
  7. Do one or more of the following:
    To modify permission entries on Do this
    System services
    • In the console tree, click System Services.

      Where?

      • Computer Configuration
      • Windows Settings
      • Security Settings
      • System Services
    • In the details pane, right-click the service you want to change, click Properties, select the Define this policy setting check box, and then click Edit Security.
    Registry keys
    • In the console tree, right-click Registry.

      Where?

      • Computer Configuration
      • Windows Settings
      • Security Settings
      • Registry
    • Click Add Key, in Select Registry Key, click the key that you want to change, and then click OK.
    Files or folders
    • In the console tree, right-click File System.

      Where?

      • Computer Configuration
      • Windows Settings
      • Security Settings
      • File System
    • Click Add File, in Add a file or folder, click the file or folder that you want to change, and then click OK.
  8. Do one of the following:
    • To set permissions for a group or user that does not appear in the Group or user names box, click Add. Type the name of the group or user you want to set permissions for, and then click OK.
    • To change or remove permissions from an existing group or user, click the name of the group or user.
  9. Do one of the following:
    • To allow a permission, in the Permissions for User or Group box, select the Allow check box.
    • To deny a permission, in the Permissions for User or Group box, select the Deny check box.
    • To remove the group or user from Group or user names, click Remove.

Notes

  • XOX
  • XOX
  • XOX
  • To complete this procedure, the computer must be joined to an Active Directory domain, and you must have permission to edit the Group Policy object.
  • These settings are refreshed on an ongoing basis, so configuring many access control lists through Group Policy may increase the load on the network.
  • In the Windows Server 2003 family, the Everyone group no longer includes Anonymous Logon.
  • You can set file and folder permissions only on drives that are formatted to use NTFS.
  • To change permissions, you must be the owner or have been granted permission to do so by the owner.
  • For more information about permissions on other objects, see Permissions.

Related Topics


Take ownership of a file or folder

Microsoft Windows graphic

To take ownership of a file or folder

  1. Open Windows Explorer, and then locate the file or folder you want to take ownership of.
  2. Right-click the file or folder, click Properties, and then click the Security tab.
  3. Click Advanced, and then click the Owner tab.
  4. In the Change owner to box, do one of the following:
    • To change the owner to a user or group that is not listed, double-click Other users and groups and, in Enter the object name to select (examples), type the name of the user or group, and then click OK.
    • To change the owner to a user or group that is listed, click the new owner.
  5. (Optional) To change the owner of all subcontainers and objects within the tree, select the Replace owner on subcontainers and objects check box.

Notes

  • XOX
  • You can transfer ownership in two ways:
    • The current owner can grant the Take ownership permission to others, allowing those users to take ownership at any time. A user granted the Take ownership permission can take ownership of the object or assign ownership to any group that the user is a member of.
    • A user who has the Restore files and directories privilege can double-click Other users and groups and choose any user or group to assign ownership to.
  • An administrator can take ownership of any file on the computer.
  • In the Windows Server 2003 family, the Everyone group no longer includes the Anonymous Logon group.

Related Topics


View effective permissions on files and folders

Microsoft Windows graphic

To view effective permissions on files and folders

  1. Open Windows Explorer, and then locate the file or folder for which you would like to view effective permissions.
  2. Right-click the file or folder, click Properties, and then click the Security tab.
  3. Click Advanced, click the Effective Permissions tab, and then click Select.
  4. In Enter the object name to select (examples), enter the name of a user or group and then click OK. The selected check boxes indicate the effective permissions of the user or group for that file or folder.

Notes

  • XOX
  • If the specified object grants access to the Everyone group, the Authenticated Users group or the Local Users group, then the effective rights will always include those permissions, except when the specified user or group is the Anonymous group. XOX and the Windows Server 2003 family no longer include the Anonymous users in the Everyone group.
  • The Effective Permissions tab shows information that is calculated from the existing permissions entries. Therefore, the information displayed on that page is read-only and does not support changing a user's permissions by selecting or clearing permission check boxes.
  • Permissions are set only on drives formatted to use NTFS.
  • Share permissions are not part of the effective permissions calculation. Access to shares can be denied though share permissions even when access is allowed through NTFS permissions.

Related Topics


Concepts

This section provides general background information about Access Control:

  • Access control overview
  • Understanding access control
  • Using access control
  • Resources


Access control overview

Access control is the process of authorizing users, groups, and computers to access objects on the network. Key concepts that make up access control are permissions, user rights, and object auditing.

Permissions

Permissions define the type of access granted to a user or group for an object or object property. For example, the Finance group can be granted Read and Write permissions for a file named Payroll.dat.

Permissions are applied to any secured objects such as files, Active Directory® objects, or registry objects. Permissions can be granted to any user, group, or computer. It is a good practice to assign to groups.

You can assign permissions for objects to:

  • Groups, users, and special identities in the domain.
  • Groups and users in that domain and any trusted domains.
  • Local groups and users on the computer where the object resides.

The permissions attached to an object depend on the type of object. For example, the permissions that can be attached to a file are different from those that can be attached to a registry key. Some permissions, however, are common to most types of objects. These common permissions are:

  • Read permissions
  • Modify permissions
  • Change owner
  • Delete

When you set up permissions, you specify the level of access for groups and users. For example, you can let one user read the contents of a file, let another user make changes to the file, and prevent all other users from accessing the file. You can set similar permissions on printers so that certain users can configure the printer and other users can only print from it.

If you need to change the permissions on an individual object, you can simply start the appropriate tool and change the properties for that object. For example, to change the permissions on a file, you can run Windows Explorer, right-click the file name, and click Properties. On the Security tab, you can change permissions on the file. For more information, see Permissions.

Ownership of objects

An owner is assigned to an object when that object is created. By default, the owner is the creator of the object. No matter what permissions are set on an object, the owner of the object can always change the permissions on an object. For more information, see Ownership.

Inheritance of permissions

Inheritance allows administrators to easily assign and manage permissions. This feature automatically causes objects within a container to inherit all the inheritable permissions of that container. For example, the files within a folder, when created, inherit the permissions of the folder. Only permissions marked to be inherited will be inherited.

User rights

User rights grant specific privileges and logon rights to users and groups in your computing environment. For information on user rights, see the following: For more information, see Introduction to user rights.

Object auditing

You can audit users' access to objects. You can then view these security-related events in the security log with the Event Viewer. For more information, see Auditing.

For more information about authorization and access control, see the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/) For information about authorization strategy, see "Designing an Authorization Strategy" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)


Understanding access control

This section covers:

  • Permissions and security descriptors
  • User rights
  • Explicit vs. inherited permissions
  • Ownership
  • Effective permissions
  • How inheritance affects file and folder permissions
  • Security identifiers


Permissions and security descriptors

Every container and object on the network has a set of access control information attached to it. Known as a security descriptor, this information controls the type of access allowed to users and groups. The security descriptor is automatically created along with the container or object that is created. A typical example of an object with a security descriptor is a file.

Permissions are defined within an object's security descriptor. Permissions are associated with, or assigned to, specific users and groups. For example, for the file Temp.dat, the Administrator group might be assigned read, write, and delete permissions, while the Operator group might be assigned Read and Write permissions only.

Each assignment of permissions to a user or group is known as a permission entry, which is a type of access control entry (ACE). The entire set of permission entries in a security descriptor is known as a permission set or access control list (ACL). Thus, for a file named Temp.dat, the permission set includes two permission entries, one for the Administrator group and one for the Operator group.


Explicit vs. inherited permissions

There are two types of permissions: explicit permissions and inherited permissions.

  • Explicit permissions are those that are set by default when the object is created, by user action.
  • Inherited permissions are those that are propagated to an object from a parent object. Inherited permissions ease the task of managing permissions and ensure consistency of permissions among all objects within a given container.

By default, objects within a container inherit the permissions from that container when the objects are created. For example, when you create a folder called MyFolder, all subfolders and files created within MyFolder automatically inherit the permissions from that folder. Therefore, MyFolder has explicit permissions, while all subfolders and files within it have inherited permissions.

Notes

  • Inherited Deny permissions do not prevent access to an object if the object has an explicit Allow permission entry.
  • Explicit permissions take precedence over inherited permissions, even inherited Deny permissions.

For more information on inherited permissions, see How inheritance affects file and folder permissions.


Ownership

Every object has an owner, whether in an NTFS volume or Active Directory. The owner controls how permissions are set on the object and to whom permissions are granted.

Important

  • An administrator who needs to repair or change permissions on a file must begin by taking ownership of the file.

By default, in the Windows Server 2003 family, the owner is the Administrators group. The owner can always change permissions on an object, even when denied all access to the object.

Ownership can be taken by:

  • An administrator. By default, the Administrators group is given the Take ownership of files or other objects user right.
  • Anyone or any group who has the Take ownership permission on the object in question.
  • A user who has the Restore files and directories privilege.

Ownership can be transferred in the following ways:

  • The current owner can grant the Take ownership permission to another user, allowing that user to take ownership at any time. The user must actually take ownership to complete the transfer.
  • An administrator can take ownership.
  • A user who has the Restore files and directories privilege can double-click Other users and groups and choose any user or group to assign ownership to.

For more information, see To take ownership of a file or folder and Restore files and directories.


Effective Permissions tool

If you would like to find out what permissions a user or group has on an object, you can use the Effective Permissions tool. It calculates the permissions that are granted to the specified user or group. The calculation takes the permissions in effect from group membership into account, as well as any permissions inherited from the parent object. It looks up all domain and local groups in which the user or group is a member.

The Everyone group will always be included, as long as the selected user or group is not a member of the Anonymous Logon group. In the Windows Server 2003 family, the Everyone group no longer includes Anonymous Logon.

Important

  • The Effective Permissions tool only produces an approximation of the permissions that a user has. The actual permissions the user has may be different, since permissions can be granted or denied based on how a user logs on. This logon-specific information cannot be determined by the Effective Permissions tool, since the user is not logged on; therefore, the effective permissions it displays reflect only those permissions specified by the user or group and not the permissions specified by the logon.

    For example, if a user is connected to this computer via a file share, then the logon for that user is marked as a network logon. Permissions can be granted or denied to the well-known security ID (SID) Network which the connected user receives, so a user has different permissions when logged on locally than when logged on over a network. For information about shared folders and share permissions, see Shared Folders and Share permissions.

    For information about granting access for effective permissions, see article Q331951 in the Microsoft Knowledge Base.(http://support.microsoft.com/)

Factors that are used to determine effective permissions

  • Global group membership
  • Local group membership
  • Local permissions
  • Local privileges

Factors that are not used to determine effective permissions

The following well-known SIDs that are available in the Windows Server 2003 family are not used to determine effective permissions:

  • Anonymous Logon
  • Batch, Creator Group
  • Dialup
  • Enterprise Domain Controllers
  • Interactive
  • Network
  • Proxy
  • Restricted
  • Remote
  • Service
  • System
  • Terminal Server User
  • Other Organization
  • This Organization

Also, share permissions are not part of the effective permissions calculation. Access to shares can be denied through share permissions even when access is allowed through NTFS permissions.

Factors that are not used for objects that are accessed remotely

  • Local group membership
  • Local privileges
  • Share permissions

Retrieving effective permissions

Accurate retrieval of the above information requires permission to read the membership information. If the specified user or group is a domain object, you must have permission to read the object's group information on the domain. Here are some relevant default domain permissions:

  • Domain administrators have permission to read membership information on all objects.
  • Local administrators on a workstation or stand-alone server cannot read membership information for a domain user.
  • Authenticated domain users can only read membership information when the domain is in Pre-Windows 2000 compatibility mode.

For more information, see To view effective permissions on files and folders and Security identifiers.


How inheritance affects file and folder permissions

After you set permissions on a parent folder, new files and subfolders that are created in the folder inherit these permissions. If you do not want them to inherit permissions, select This folder only in Apply onto when you set up special permissions for the parent folder. In cases where you want to prevent only certain files or subfolders from inheriting permissions, right-click the file or subfolder, click Properties, click the Security tab, click Advanced, and then clear the Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here. check box.

If the check boxes appear shaded, the file or folder has inherited permissions from the parent folder. There are three ways to make changes to inherited permissions:

  • Make the changes to the parent folder, and then the file or folder will inherit these permissions.
  • Select the opposite permission (Allow or Deny) to override the inherited permission.
  • Clear the Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here. check box. You can then make changes to the permissions or remove the user or group from the permissions list. However, the file or folder will no longer inherit permissions from the parent folder.

In most cases, Deny overrides Allow unless a folder is inheriting conflicting settings from different parents. In that case, the setting inherited from the parent closest to the object in the subtree will have precedence.

Only inheritable permissions are inherited by child objects. When setting permissions on the parent object, you can decide whether folders or subfolders can inherit them with Apply onto. For more information, see Selecting where to apply permissions.

You can find out what permissions a user or group has on an object with the Effective Permissions tool.

For more information, see To set, view, change, or remove file and folder permissions.


Security identifiers

Security identifiers (SIDs) are numeric values that identify a user or group. For each access control entry (ACE), there exists a SID that identifies the user or group for whom access is allowed, denied, or audited.

Well-known security identifiers (special identities)

Well-known SID | Description
Anonymous Logon (S-1-5-7) | A user who has connected to the computer without supplying a user name and password.
Authenticated Users (S-1-5-11) | Includes all users and computers whose identities have been authenticated. Authenticated Users does not include Guest even if the Guest account has a password.
Batch (S-1-5-3) | Includes all users who have logged on through a batch queue facility such as task scheduler jobs.
Creator Owner (S-1-3-0) | A placeholder in an inheritable access control entry (ACE). When the ACE is inherited, the system replaces this SID with the SID for the object's current owner.
Creator Group (S-1-3-1) | A placeholder in an inheritable ACE. When the ACE is inherited, the system replaces this SID with the SID for the primary group of the object's current owner.
Dialup (S-1-5-1) | Includes all users who are logged on to the system through a dial-up connection.
Everyone (S-1-1-0) | On computers running Windows Server 2003 operating systems, Everyone includes Authenticated Users and Guest. On computers running earlier versions of the operating system, Everyone includes Authenticated Users and Guest plus Anonymous Logon. For more information, see Differences in default security settings.
Interactive (S-1-5-4) | Includes all users logging on locally or through a Remote Desktop connection.
Local System (S-1-5-18) | A service account that is used by the operating system.
Network (S-1-5-2) | Includes all users who are logged on through a network connection. Access tokens for interactive users do not contain the Network SID.
Self (or Principal Self) (S-1-5-10) | A placeholder in an ACE on a user, group, or computer object in Active Directory. When you grant permissions to Principal Self, you grant them to the security principal represented by the object. During an access check, the operating system replaces the SID for Principal Self with the SID for the security principal represented by the object.
Service (S-1-5-6) | A group that includes all security principals that have logged on as a service. Membership is controlled by the operating system.
Terminal Server Users (S-1-5-13) | Includes all users who have logged on to a Terminal Services server that is in Terminal Services version 4.0 application compatibility mode.
Other Organization (S-1-5-1000) | Causes a check to ensure that a user from another forest or domain is allowed to authenticate to a particular service.
This Organization (S-1-5-15) | Added by the authentication server to the authentication data of a user, provided the Other Organization SID is not already present.

For more information on the Administrators (S-1-5-32-544), Power Users (S-1-5-32-547), Backup operators (S-1-5-32-551), and Users (S-1-5-32-545) groups, see Default security settings for groups.

For more information, see Well-Known Security Identifiers at the Microsoft Resource Kits Web site.(http://www.microsoft.com/)


Using access control

This section covers:

  • Permissions
  • Permissions for files and folders
  • Active Directory object permissions
  • Selecting where to apply permissions
  • Changing inherited permissions
  • Privileges
  • Logon Rights


Permissions

Each type of object is controlled by an object manager. There is a different object manager for each type of object. The object types, their object managers, and the tools you use to manage these objects are as follows:

Object Type | Permission Descriptions | Procedures
Files and folders | Permissions for files and folders | To set, view, change, or remove permissions on files and folders or To set, view, change, or remove special permissions
Shares | Share permissions | To set permissions on a shared resource
Registry keys | Maintain registry security | To add users or groups to the permissions list
Services | Services permissions | Local computer security for file system, registry, and system services
Printer | Assigning printer permissions | To set or remove permissions for a printer
Terminal Services Connections | Managing permissions on connections or Controlling connection access | Manage connection permissions
WMI object | To authorize WMI users and set permissions | To modify permissions or delete authorized users
Active Directory objects | Active Directory object permissions. Best Practices for assigning permissions on Active Directory objects. |


Special permissions for files and folders

Microsoft Windows graphic

Permissions for files and folders

Folder permissions include Full Control, Modify, Read & Execute, List Folder Contents, Read, and Write. For information about these permissions, see File and folder permissions. Each of these permissions consists of a logical group of special permissions which are listed and defined below.

Permission | Description
Traverse Folder/Execute File | For folders: Traverse Folder allows or denies moving through folders to reach other files or folders, even if the user has no permissions for the traversed folders. (Applies to folders only.) Traverse folder takes effect only when the group or user is not granted the Bypass traverse checking user right in the Group Policy snap-in. (By default, the Everyone group is given the Bypass traverse checking user right.) For files: Execute File allows or denies running program files. (Applies to files only). Setting the Traverse Folder permission on a folder does not automatically set the Execute File permission on all files within that folder.
List Folder/Read Data | List Folder allows or denies viewing file names and subfolder names within the folder. List Folder only affects the contents of that folder and does not affect whether the folder you are setting the permission on will be listed. (Applies to folders only.) Read Data allows or denies viewing data in files. (Applies to files only.)
Read Attributes | Allows or denies viewing the attributes of a file or folder, such as read-only and hidden. Attributes are defined by NTFS.
Read Extended Attributes | Allows or denies viewing the extended attributes of a file or folder. Extended attributes are defined by programs and may vary by program.
Create Files/Write Data | Create Files allows or denies creating files within the folder. (Applies to folders only). Write Data allows or denies making changes to the file and overwriting existing content. (Applies to files only.)
Create Folders/Append Data | Create Folders allows or denies creating folders within the folder. (Applies to folders only.) Append Data allows or denies making changes to the end of the file but not changing, deleting, or overwriting existing data. (Applies to files only.)
Write Attributes | Allows or denies changing the attributes of a file or folder, such as read-only or hidden. Attributes are defined by NTFS. The Write Attributes permission does not imply creating or deleting files or folders, it only includes the permission to make changes to the attributes of a file or folder. In order to allow (or deny) create or delete operations, see Create Files/Write Data, Create Folders/Append Data, Delete Subfolders and Files, and Delete.
Write Extended Attributes | Allows or denies changing the extended attributes of a file or folder. Extended attributes are defined by programs and may vary by program. The Write Extended Attributes permission does not imply creating or deleting files or folders, it only includes the permission to make changes to the attributes of a file or folder. In order to allow (or deny) create or delete operations, see Create Files/Write Data, Create Folders/Append Data, Delete Subfolders and Files, and Delete.
Delete Subfolders and Files | Allows or denies deleting subfolders and files, even if the Delete permission has not been granted on the subfolder or file. (Applies to folders.)
Delete | Allows or denies deleting the file or folder. If you do not have Delete permission on a file or folder, you can still delete it if you have been granted Delete Subfolders and Files on the parent folder.
Read Permissions | Allows or denies reading permissions of the file or folder, such as Full Control, Read, and Write.
Change Permissions | Allows or denies changing permissions of the file or folder, such as Full Control, Read, and Write.
Take Ownership | Allows or denies taking ownership of the file or folder. The owner of a file or folder can always change permissions on it, regardless of any existing permissions that protect the file or folder.
Synchronize | Allows or denies different threads to wait on the handle for the file or folder and synchronize with another thread that may signal it. This permission applies only to multithreaded, multiprocess programs.

For more information, see To set, view, change, or remove special permissions and To set, view, change, or remove permissions on files and folders.

Note

  • You will not be able to access an encrypted file without the Encrypting File System (EFS) key, even if you have the necessary permissions. For information about EFS, see Encrypting File System.


Permissions on a file server

Access on a shared folder is determined through two sets of permission entries; the permissions set on the share (called share permissions) and the permissions set on the folder (called NTFS file and folder permissions). Share permissions are often used for managing computers with FAT32 file systems, or other computers that don't use the NTFS file system.

Share Permissions and NTFS Permissions are independent in the sense that neither changes the other. The final access permissions on a shared folder are determined by taking into consideration both the Share permission and the NTFS permission entries. The more restrictive permissions are then applied.

The following table suggests permissions that a security-conscious administrator could grant to the Users group for certain shared folder types. The recommended permissions have been tested, and work correctly; but there are alternative approaches. For example, some experienced administrators prefer always to set share permissions to Full Control for Everyone, and to rely entirely on NTFS permissions to restrict access.

Folder type | Share permissions | NTFS permissions
Public folder. A folder that can be accessed by everyone. | Grant Change permission to the Users group. | Grant Modify permission to the Users group.

Drop folder. A folder where users can drop confidential reports or homework assignments that only the group manager or instructor can read.

Grant the Change permission to the Users group.

Grant the Full Control permission to the group manager.

Grant the Write permission for the users' group that is applied to This Folder only. (This is an option available on the Advanced page.) For more information, see To set, view, change, or remove special permissions.

If each user needs to have certain permissions to the files that he or she dropped, you can create a permission entry for the Creator Owner well-known security identifier (SID) and apply it to Subfolder and files only. For example, you can grant the Read and Write permission to the Creator Owner SID on the drop folder and apply it to all subfolders and files. This grants the user who dropped or created the file (the Creator Owner) the ability to read and write to the file. The Creator Owner can then access the file through the Run command using \\ServerName\DropFolder\FileName.

Grant the Full Control permission for the group manager.

Application folder. A folder containing applications that can be run over the network.

Grant Read permission for the Users group.

Grant Read, Read and Execute, and List Folder Content permissions to the Users group.
Home folders. Individual folders for each user. Only the user has access to the folder. | Grant the Full Control permission to each user on their respective folder. | Grant the Full Control permission to each user for their respective folder.

Notes

  • Granting a user Full Control NTFS permission on a folder enables that user to take ownership of the folder unless the user is restricted in some other way. Be cautious in granting Full Control.
  • If you want to manage folder access by using NTFS permissions exclusively, set Share permissions to Full Control for Everyone. This frees you from having to think about Share permissions, but NTFS permissions are more complex than Share permissions, so using NTFS permissions correctly requires deeper understanding on your part. For more information on NTFS permissions, search for the term "NTFS permissions" on TechNet on the Microsoft Web site.(http://www.microsoft.com/)
  • NTFS permissions affect access both locally and remotely. NTFS permissions apply regardless of protocol. Share permissions, by contrast, apply only to network shares. Share permissions do not restrict access to any local user, or to any terminal server user, of the computer on which you have set Share permissions. Thus, Share permissions do not provide privacy between users on a computer used by several users, nor on a terminal server accessed by several users.
  • By default, Everyone does not include Anonymous, so permissions applied to Everyone do not affect Anonymous. This default behavior is new for the Windows Server 2003 family.

For more information, see To set, view, change, or remove permissions on files and folders and To share a folder or drive.


File and folder permissions

Microsoft Windows graphic

Active Directory object permissions

Extended rights

These permissions are for a special operation on an Active Directory object, where the operation is not necessarily related to read or write access to a particular attribute on that object.

Extended right | Description
Applies to Computers and Users |
Receive As Applies to: Computer and User | Exchange right: allows receiving mail as a given mailbox.
Send As Applies to: User, computer, and inetOrgPerson | Exchange right: allows sending mail as the mailbox.
Send To Applies to: Group | Exchange right: allows sending to a mailbox.
Change Password | Permits changing password on user account. You do need to know the original password to be able to make the change.
Reset Password Applies to: User, computer, and inetOrgPerson | Permits resetting password on user account. With this permission, when you reset the password, you do not need to know the original password.
Applies to Domain-DNS |
Replicating Directory Changes Applies to: Domain-DNS | Extended right needed to replicate changes from a given NC.
Add/Remove Replica In Domain Applies to: Domain-DNS | Extended right needed to do a replica install.
Add GUID Applies to: Domain-DNS | Extended right needed at the NC root to add an object with a specific GUID.
Change PDC Applies to: Domain-DNS | Extended right needed to change the PDC.
Manage Replication Topology Applies to: Domain-DNS | Extended right needed to update the replication topology for a given NC.
Replication Synchronization Applies to: Domain-DNS, DMD, Configuration | Extended right needed to synchronize replication from a given computer.
Generate Resultant Set of Policy (Logging) Applies to: Domain-DNS, Organizational-Unit | The user who has the rights on an organizational unit or domain will be able to generate logging mode Resultant Set of Policy (RSoP) data for the users/computers within the organizational unit.
Generate Resultant Set of Policy (Planning) Applies to: Domain-DNS, Organizational-Unit | The user who has the rights on an organizational unit or domain will be able to generate planning mode RSoP data for the users or computers within the organizational unit.
Applies to NTDS-DSA |
Allocate Rids | Extended right needed to request RID pool.
Do Garbage Collection Applies to: NTDS-DSA | Extended right to force the directory service to do garbage collection. Control right to force the directory service to do garbage collection.
Recalculate Hierarchy Applies to: NTDS-DSA | Extended right to force the directory service to recalculate the hierarchy.
Applies to a Group Policy container |
Apply Group Policy | Extended right to determine if a Group Policy object applies or not. For a Group Policy object to apply to a user group or computer, the Apply Group Policy and Read permissions must be set.
Applies to Site |
Open Connector Queue | Allows opening connector queue.

Validated writes

A validated write is different from a write permission which does not allow for any value checking. The value checking, or validation, ensures that the value conforms to required semantics, is within a legal range of values, or undergoes some other special checking that would not be performed for a simple low-level write to the property.

Validated write | Description
Add/remove self as member Applies to: Group | Validated write permission to enable one to add or remove one's own account from membership of a group.
Validated write to DNS host name Applies to: Computer | Validated write permission to enable setting of a DNS host name attribute that is compliant with the computer name and domain name.
Validated write to service principal name Applies to: Computer | Validated write permission to enable setting of the SPN attribute which is compliant to the DNS host name of the computer.

Property sets

A property set consists of a group of related properties (or attributes). Granting access rights to a property set rather than to individual properties greatly improves performance and simplifies security management.

Domain Password

Password and account lockout properties for the domain are stored in the Directory Service as attributes of the domain object. These properties can also be managed through the user interface using the Domain Security Policy Group Policy object, the values are then sychronized to the Directory Service. Password policies as well as all account policies are domainwide and applied to all members of the domain.

Applies to: Domain
  • lockOutObservationWindow
  • lockoutDuration
  • lockoutThreshold
  • maxPwdAge
  • minPwdAge
  • minPwdLength
  • Pwd-Properties

Other Domain Parameters (for use by the security account manager, also called SAM)

Property set permitting control to a list of domain attributes.

Applies to: Domain
  • domainReplica
  • forceLogoff
  • modifiedCount
  • oEMInformation
  • serverRole
  • serverState
  • uASCompat

E-mail Information

Property set that contains user attributes that describe user e-mail information.

Applies to: Group, User

General Information

Property set containing a set of user attributes that constitute general user information.

Applies to: User
  • Display Name
  • adminDescription
  • codePage
  • CountryCode
  • ObjectSid
  • primaryGroupID
  • sAMAccountName
  • sAMAccountType
  • sDRightsEffective
  • showInAdvancedViewOnly
  • sIDHistory
  • UID
  • comment

Membership

Property set containing user attributes that describe group membership information.

Applies to: User
  • memberOf
  • member

Personal Information

Property set containing user attributes that describe personal user information.

Applies to: Computer, Contact, User
  • streetAddress
  • homePostalAddress
  • assistant
  • info
  • country/region name
  • facsimileTelephoneNumber (fax number)
  • International-ISDN-Number
  • Locality-Name
  • MSMQ-Digests
  • mSMQSignCertificates
  • Personal-Title
  • Phone-Fax-Other
  • Phone-Home-Other
  • Phone-Home-Primary
  • otherIpPhone
  • ipPhonenumber
  • primaryInternationalISDNNumber Phone-ISDN-Primary
  • Phone-Mobile-Other (otherMobile)
  • Phone-Mobile-Primary
  • Phone-Office-Other (otherTelephone)
  • Phone-Pager-Other
  • Phone-Pager-Primary
  • physicalDeliveryOfficeName
  • thumbnailPhoto (Picture)
  • postalCode
  • preferredDeliveryMethod
  • registeredAddress
  • State-Or-Province-Name
  • Street-Address
  • telephoneNumber
  • teletexTerminalIdentifier
  • telexNumber
  • primaryTelexNumber
  • userCert
  • User-Shared-Folder
  • User-Shared-Folder-Other
  • userSMIMECertificate
  • x121Address
  • X509-Cert

Public Information

Property set containing user attributes that describe user public information.

Applies to: Computer, User
  • Additional-Information notes
  • Allowed-Attributes
  • allowedAttributesEffective
  • allowedChildClasses
  • allowedChildClassesEffective
  • altSecurityIdentities
  • Common-Name (cn)
  • company
  • department
  • description
  • displayNamePrintable
  • division
  • E-mail-Addresses
  • givenName
  • initials
  • legacyExchangeDN
  • manager
  • msDS-Approx-Immed-Subordinates
  • msDS-Auxiliary-Classes
  • distinguishedName (Obj-Dist-Name)
  • Object-Category
  • Object-Class
  • Object-Guid
  • Organization-Name
  • Organizational-Unit-Name
  • otherMailbox
  • Proxy-Addresses
  • RDN name
  • Reports (directReports)
  • servicePrincipalName
  • showInAddressBook
  • Surname
  • System-Flags
  • Text-Country/Region
  • Title
  • userPrincipalName

RAS Information

System Internal: Do not use or modify this right.

Applies to: User
  • msNPAllowDialin
  • msNPCallingStationID
  • msRADIUSCallbackNumber
  • msRADIUSFramedIPAddress
  • msRADIUSFramedRoute
  • msRADIUSServiceType
  • tokenGroups
  • Token-Groups-Global-And-Universal

User Account Restrictions

Property set containing user attributes that describe account restrictions.

Applies to: Computer, User
  • accountExpires
  • pwdLastSet
  • userAccountControl
  • userParameters
  • tokenGroupsNoGCAcceptable

User Logon

Property set containing user attributes that describe user logon information.

Applies to: User
  • badPwdCount
  • homeDirectory
  • homeDrive
  • lastLogoff
  • Last-Logon
  • lastLogonTimestamp
  • logonCount
  • logonHours
  • logonWorkstation
  • profilePath

Web Information Contact

Property set containing user attributes that describe user web related information.

Applies to: Web Information Contact, User
  • WWWHomePage
  • WWW-Page-Other url

For a complete list of Active Directory permissions, see the MSDN home page on the Microsoft Web site (http://www.microsoft.com/).


Selecting where to apply permissions

When you set advanced permissions on files and folders, you can use Permission Entry for File or Folder Name to set which folders or subfolders will inherit permissions. In this dialog box, Apply onto lists the locations where you can apply permissions. How these permissions are applied depends on whether you select the Apply these permissions to objects and/or containers within this container only check box. By default, this check box is cleared.

Important

  • For Active Directory objects, not only will the specified objects in the Apply onto field inherit the access control entries but ALL child objects will receive a copy of that ACE. The child objects not specified in the Apply onto field will not utilize the ACE whose copy they receive but if there are enough objects that will get copies of this ACE, then that increased amount of data can cause serious performance problems to your network. For more information, see Best practices for assigning permissions on Active Directory objects in Help.

For more information, see How inheritance affects file and folder permissions.

When the Apply these permissions to objects and/or containers within this container only check box is cleared

Apply onto | Applies permissions to current folder | Applies permissions to subfolders in current folder | Applies permissions to files in current folder | Applies permissions to all subsequent subfolders | Applies permissions to files in all subsequent subfolders
This folder only | x |  |  |  |
The folder, subfolders and files | x | x | x | x | x
This folder and subfolders | x | x |  | x |
This folder and files | x |  | x |  | x
Subfolders and files only |  | x | x | x | x
Subfolders only |  | x |  | x |
Files only |  |  | x |  | x

When the Apply these permissions to objects and/or containers within this container only check box is selected

Apply onto | Applies permissions to current folder | Applies permissions to subfolders in current folder | Applies permissions to files in current folder | Applies permissions to all subsequent subfolders | Applies permissions to files in all subsequent subfolders
This folder only | x |  |  |  |
The folder, subfolders and files | x | x | x |  |
This folder and subfolders | x | x |  |  |
This folder and files | x |  | x |  |
Subfolders and files only |  | x | x |  |
Subfolders only |  | x |  |  |
Files only |  |  | x |  |

For more information, see To set, view, change, or remove special permissions.


Changing inherited permissions

Inheritance for all objects

If the check boxes are shaded when you view the permissions of an object, the object has inherited permissions from the parent object. There are three ways to make changes to inherited permissions:

  • Make the changes to the parent object, and then the child object will inherit these permissions.
  • Select the opposite permission (Allow or Deny) to override the inherited permission.
  • Clear the Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here check box. Then you can make changes to the permissions or remove users or groups from the Permissions list. However, the object will no longer inherit permissions from the parent object.

Notes

  • Inherited Deny permissions do not prevent access to an object if the object has an explicit Allow permission entry.
  • Explicit permissions take precedence over inherited permissions, even inherited Deny permissions. For more information, see Explicit vs. inherited permissions.

On the Advanced page, in Permission entries, the Apply To column lists what folders or subfolders a permission is applied to. The Inherited From column lists where the permissions have been inherited from.

You can use the Apply onto field to select the folders or subfolders you would like permissions to be applied to. For more information, see Explicit vs. inherited permissions.

If the Special Permissions entry in Permissions for User or Group is shaded, it does not imply that this permission has been inherited. This means that a special permission has been selected. For more information, see To set, view, change, or remove special permissions for files and folders and Selecting where to apply permissions.

Inheritance for Active Directory objects

For Active Directory objects, when using the Apply Onto option to control inheritance, be aware that not only will the objects specified in the Apply onto field inherit that access control entry (ACE) but all child objects will also receive a copy of that ACE. The child objects that are not specified in the Apply onto field will receive copies of the ACE but will not enforce it. If there are enough objects that will get copies of this ACE, then that increased amount of data can cause serious performance problems to your network.

If you assign permissions to a parent object and want child objects to inherit these permission entries, you can keep performance optimal by making sure all the child objects have identical access control lists (ACLs). In the Windows Server 2003 family single-instancing allows for the Active Directory to store only one copy of all identical ACLs. By creating ACLs that many objects can utilize, you can preserve the performance of your network.


File and folder permissions

Special Permissions | Full Control | Modify | Read & Execute | List Folder Contents(folders only) | Read | Write
Traverse Folder/Execute File | x | x | x | x |  |
List Folder/Read Data | x | x | x | x | x |
Read Attributes | x | x | x | x | x |
Read Extended Attributes | x | x | x | x | x |
Create Files/Write Data | x | x |  |  |  | x
Create Folders/Append Data | x | x |  |  |  | x
Write Attributes | x | x |  |  |  | x
Write Extended Attributes | x | x |  |  |  | x
Delete Subfolders and Files | x |  |  |  |  |
Delete | x | x |  |  |  |
Read Permissions | x | x | x | x | x | x
Change Permissions | x |  |  |  |  |
Take Ownership | x |  |  |  |  |
Synchronize | x | x | x | x | x | x

Important

  • Groups or users granted Full Control on a folder can delete any files in that folder regardless of the permissions protecting the file.

Notes

  • Although List Folder Contents and Read & Execute appear to have the same special permissions, these permissions are inherited differently. List Folder Contents is inherited by folders but not files, and it should only appear when you view folder permissions. Read & Execute is inherited by both files and folders and is always present when you view file or folder permissions.
  • For information on setting permissions and descriptions of each special permission, see Related Topics.
  • In the Windows Server 2003 family, by default, Everyone does not include Anonymous, so permissions applied to Everyone do not affect Anonymous.

For more information, see To set, view, change, or remove permissions on files and folders and To set, view, change, or remove special permissions.


Troubleshooting

What problem are you having?

I've denied the Everyone group access to an object, but not even administrators have access to it.

Cause: Everyone means everyone including administrators.

Solution: The owner of the object must change the permission entries on the object. The owner of an object always has the right to change the permission entries.

See also: Ownership

I'm connected to a remote computer using my credentials, but I cannot modify the Access Control List of remote resources.

Cause: You have authenticated to the remote computer using an authentication mechanism that does not support ADSI, so the credentials cannot be used to authenticate ADSI communication. This is the type of communication that is used to set or modify the Access Control List in some cases.

Solution: Close the application you are using. Close all connections to the remote computer by typing net use * /d at a command prompt, then start the application that you are using to modify the Access Control List. This will force the application to perform a new authentication using the appropriate mechanism.

See also: Net use